W-CDMA (Wideband Code Division Multiple Access) is a radio interface for IMT-2000 (International Mobile Communication), which was standardized for use as the 3rd generation wireless mobile telecommunication system. It provides a variety of services such as voice services and multimedia mobile communication services in a flexible and efficient way. The standardization bodies in Japan, Europe, USA, and other countries have jointly organized a project called the 3rd Generation Partnership Project (3GPP) to produce common radio interface specifications for W-CDMA.
The standardized European version of IMT-2000 is commonly called UMTS (Universal Mobile Telecommunication System). The first release of the specification of UMTS has been published in 1999 (Release 99). In the mean time several improvements to the standard have been standardized by the 3GPP in Release 4 and Release 5 and discussion on further improvements is ongoing under the scope of Release 6.
The dedicated channel (DCH) for downlink and uplink and the downlink shared channel (DSCH) have been defined in Release 99 and Release 4. In the following years, the developers recognized that for providing multimedia services—or data services in general—high speed asymmetric access had to be implemented. In Release 5 the high-speed downlink packet access (HSDPA) was introduced. The new high-speed downlink shared channel (HS-DSCH) provides downlink high-speed access to the user from the UMTS Radio Access Network (RAN) to the communication terminals, called user equipments (UE) in the UMTS specifications.
UMTS Architecture
The high level Release 99/4/5 architecture of Universal Mobile Telecommunication System (UMTS) is shown in FIG. 1 (see 3GPP TR 25.401: “UTRAN Overall Description”, incorporated herein by reference and available from http://www.3gpp.org). The network elements are functionally grouped into the Core Network (CN) 101, the UMTS Terrestrial Radio Access Network (UTRAN) 102 and the User Equipment (UE) 103. The UTRAN 102 is responsible for handling all radio-related functionality, while the CN 101 is responsible for routing calls and data connections to external networks. The interconnections of these network elements are defined by open interfaces (Iu, Uu). It should be noted that UMTS system is modular and it is therefore possible to have several network elements of the same type.
In the sequel two different architectures will be discussed. They are defined with respect to logical distribution of functions across network elements. In actual network deployment, each architecture may have different physical realizations meaning that two or more network elements may be combined into a single physical node.
FIG. 2 illustrates the current architecture of UTRAN. A number of Radio Network Controllers (RNCs) 201, 202 are connected to the CN 101. Each RNC 201, 202 controls one or several base stations (Node Bs) 203, 204, 205, 206, which in turn communicate with the user equipments. An RNC controlling several base stations is called Controlling RNC (C-RNC) for these base stations. A set of controlled base stations accompanied by their C-RNC is referred to as Radio Network Subsystem (RNS) 207, 208. For each connection between User Equipment and the UTRAN, one RNS is the Serving RNS (S-RNS). It maintains the so-called lu connection with the Core Network (CN) 101. When required, the Drift RNS 302 (D-RNS) 302 supports the Serving RNS (S-RNS) 301 by providing radio resources as shown in FIG. 3. Respective RNCs are called Serving RNC (S-RNC) and Drift RNC (D-RNC). It is also possible and often the case that C-RNC and D-RNC are identical and therefore abbreviations S-RNC or RNC are used. Commonly, a Drift RNS 302 is used for soft handovers of UEs between different RNS.
Enhanced Uplink Dedicated Channel (E-DCH)
Uplink enhancements for Dedicated Transport Channels (DTCH) were studied by the 3GPP Technical Specification Group RAN (see 3GPP TR 25.896: “Feasibility Study for Enhanced Uplink for UTRA FDD (Release 6)”, incorporated herein by reference and available at http://www.3gpp.org). Since the use of IP-based services become more important, there is an increasing demand to improve the coverage and throughput of the RAN as well as to reduce the delay of the uplink dedicated transport channels. Streaming, interactive and background services could benefit from this enhanced uplink. One enhancement is the usage of adaptive modulation and coding schemes (AMC) in connection with Node B controlled scheduling, thus an enhancement of the Uu interface. In the existing R99/R4/R5 system the uplink maximum data rate control resides in the RNC. By relocating the scheduler in the Node B the latency introduced due to signaling on the interface between RNC and Node B may be reduced and thus the scheduler may be able to respond faster to temporal changes in the uplink load. This may reduce the overall latency in communications of the user equipment with the RAN. Therefore Node B controlled scheduling is capable of better controlling the uplink interference and smoothing the noise rise variance by allocating higher data rates quickly when the uplink load decreases and respectively by restricting the uplink data rates when the uplink load increases. The coverage and cell throughput may be improved by a better control of the uplink interference.
Another technique, which may be considered to reduce the delay on the uplink, is introducing a shorter TTI (Transmission Time Interval) length for the E-DCH compared to other transport channels. A transmission time interval length of 2 ms is currently investigated for use on the E-DCH, while a transmission time interval of 10 ms is commonly used on the other channels. Hybrid ARQ, which was one of the key technologies in HSDPA, is also considered for the enhanced uplink dedicated channel. The Hybrid ARQ protocol between a Node B and a user equipment allows for rapid retransmissions of erroneously received data units, and may thus reduce the number of RLC (Radio Link Control) retransmissions and the associated delays. This may improve the quality of service experienced by the end user.
To support enhancements described above, a new MAC sub-layer is introduced which will be called MAC-e in the following (see 3GPP TSG RAN WG1, meeting #31, Tdoc R01-030284, “Scheduled and Autonomous Mode Operation for the Enhanced Uplink” incorporated herein by reference). The entities of this new sub-layer, which will be described in more detail in the following sections, may be located in user equipment and Node B. On user equipment side, the MAC-e performs the new task of multiplexing upper layer data (e.g. MAC-d) data into the new enhanced transport channels and operating HARQ protocol transmitting entities.
Further, the MAC-e sub-layer may be terminated in the S-RNC during handover at the UTRAN side. Thus, the reordering buffer for the reordering functionality provided may also reside in the S-RNC.
E-DCH MAC Architecture—UE Side
FIG. 4 shows the exemplary overall E-DCH MAC architecture on UE side. A new MAC functional entity, the MAC-e/es, is added to the MAC architecture of Release '99. The MAC interworking on the UE side is illustrated in FIG. 5. Several MAC-d flows carry data packets from different applications to be transmitted from UE to Node B. These data flows can have different QoS requirements (e.g. delay and error requirements) and may require different configuration of HARQ instances. Each MAC-d flow represents a logical unit to which specific physical channel (e.g. gain factor) and HARQ (e.g. maximum number of retransmissions) attributes can be assigned.
Further, MAC-d multiplexing is supported for an E-DCH, i.e. several logical channels with different priorities may be multiplexed onto the same MAC-d flow. Data of multiple MAC-d flows can be multiplexed in one MAC-e PDU (protocol data unit). In the MAC-e header, the DDI (Data Description Indicator) field identifies logical channel, MAC-d flow and MAC-d PDU size. A mapping table is signaled over RRC, to allow the UE to set DDI values. The N field indicates the number of consecutive MAC-d PDUs corresponding to the same DDI value.
The MAC-e/es entity is depicted in more detail in FIG. 6. The MAC-es/e handles the E-DCH specific functions. The selection of an appropriate transport format for the transmission of data on E-DCH is done in the E-TFC Selection entity, which represents a function entity. The transport format selection is done according to the scheduling information (Relative Grants and Absolute Grants) received from UTRAN via L1, the available transmit power, priorities, e.g. logical channel priorities. The HARQ entity handles the retransmission functionality for the user. One HARQ entity supports multiple HARQ processes. The HARQ entity handles all HARQ related functionalities required. The multiplexing entity is responsible for concatenating multiple MAC-d PDUs into MAC-es PDUs, and to multiplex one or multiple MAC-es PDUs into a single MAC-e PDU, to be transmitted at the next TTI, and as instructed by the E-TFC selection function. It is also responsible for managing and setting the TSN per logical channel for each MAC-es PDU. The MAC-e/es entity receives scheduling information from Node B (network side) via Layer 1 signaling as shown in FIG. 6. Absolute grants are received on E-AGCH (Enhanced Absolute Grant Channel), relative grants are received on the E-RGCH (Enhanced Relative Grant Channel).
E-DCH MAC Architecture—UTRAN Side
An exemplary overall UTRAN MAC architecture is shown in FIG. 7. The UTRAN MAC architecture includes a MAC-e entity and a MAC-es entity. For each UE that uses an E-DCH, one MAC-e entity per Node-B and one MAC-es entity in the S-RNC are configured. The MAC-e entity is located in the Node B and controls access to the E-DCH. Further, the MAC-e entity is connected to MAC-es located in the S-RNC.
In FIG. 8 the MAC-e entity in Node B is depicted in more detail. There is one MAC-e entity in Node B for each UE and one E-DCH scheduler function in the Node-B for all UEs. The MAC-e entity and E-DCH scheduler handle HSUPA (High-Speed Uplink Packet Access) specific functions in Node B. The E-DCH scheduling entity manages E-DCH cell resources between UEs. Commonly, scheduling assignments are determined and transmitted based on scheduling requests from the UEs. The De-multiplexing entity in the MAC-e entity provides de-multiplexing of MAC-e PDUs. MAC-es PDUs are then forwarded to the MAC-es entity in the S-RNC.
One HARQ entity is capable of supporting multiple instances (HARQ processes), e.g. employing a stop and wait HARQ protocols. Each HARQ process is assigned a certain amount of the soft buffer memory for combining the bits of the packets from outstanding retransmissions. Furthermore each process is responsible for generating ACKs or NACKs indicating delivery status of E-DCH transmissions. The HARQ entity handles all tasks that are required for the HARQ protocol.
In FIG. 9 the MAC-es entity in the S-RNC is shown. It comprises the reordering buffer which provides in-sequence delivery to RLC and handles the combining of data from different Node Bs in case of soft handover. The combining is referred to as Macro diversity selection combining.
It should be noted that the required soft buffer size depends on the used HARQ scheme, e.g. an HARQ scheme using incremental redundancy (IR) requires more soft buffer than one with chase combining (CC).
Packet Scheduling
Packet scheduling may be a radio resource management algorithm used for allocating transmission opportunities and transmission formats to the users admitted to a shared medium. Scheduling may be used in packet based mobile radio networks in combination with adaptive modulation and coding to maximize throughput/capacity by e.g. allocating transmission opportunities to the users in favorable channel conditions. The packet data service in UMTS may be applicable for the interactive and background traffic classes, though it may also be used for streaming services. Traffic belonging to the interactive and background classes is treated as non real time (NRT) traffic and is controlled by the packet scheduler. The packet scheduling methodologies can be characterized by:                Scheduling period/frequency: The period over which users are scheduled ahead in time.        Serve order: The order in which users are served, e.g. random order (round robin) or according to channel quality (C/I or throughput based).        Allocation method: The criterion for allocating resources, e.g. same data amount or same power/code/time resources for all queued users per allocation interval.        
In 3GPP UMTS R99/R4/R5, the packet scheduler for uplink is distributed between Radio Network Controller (RNC) and user equipment (UE). On the uplink, the air interface resource to be shared by different users is the total received power at a Node B, and consequently the task of the scheduler is to allocate the power among the user equipment(s). In current UMTS R99/R4/R5 specifications the RNC controls the maximum rate/power a user equipment is allowed to transmit during uplink transmission by allocating a set of different transport formats (modulation scheme, code rate, etc.) to each user equipment.
The establishment and reconfiguration of such a TFCS (transport format combination set) may be accomplished using Radio Resource Control (RRC) messaging between RNC and user equipment. The user equipment is allowed to autonomously choose among the allocated transport format combinations based on its own status e.g. available power and buffer status. In current UMTS R99/R4/R5 specifications there is no control on time imposed on the uplink user equipment transmissions. The scheduler may e.g. operate on transmission time interval basis.
E-DCH—Node B Controlled Scheduling
Node B controlled scheduling is one of the technical features for E-DCH which may enable more efficient use of the uplink resources in order to provide a higher cell throughput in the uplink and may increase the coverage. The term “Node B controlled scheduling” denotes the possibility for a Node B to control uplink resources, e.g. the E-DPDCH/DPCCH power ratio, which the UE may use for uplink transmissions on the E-DCH within limits set by the S-RNC. Node B controlled scheduling is based on uplink and downlink control signaling together with a set of rules on how the UE should behave with respect to this signaling.
In the downlink, a resource indication (scheduling grant) is required to indicate to the UE the (maximum) amount of uplink resources it may use. When issuing scheduling grants, the Node B may use QoS-related information provided by the S-RNC and from the UE in the scheduling requests to determine the appropriate allocation of resources for servicing the UE at the requested QoS parameters.
For the UMTS E-DCH, there are commonly two different UE scheduling modes defined depending on the type of scheduling grants used. In the following the characteristics of the scheduling grants are described.
Scheduling Grants
Scheduling grants are signaled in the downlink in order to indicate the (maximum) resource the UE may use for uplink transmissions. The grants affect the selection of a suitable transport format (TF) for the transmission on the E-DCH (E-TFC selection). However, they usually do not influence the TFC selection (Transport Format Combination) for legacy dedicated channels.
There are commonly two types of scheduling grants which are used for the Node B controlled scheduling:                absolute grants (AGs), and        relative grants (RGs)        
The absolute grants provide an absolute limitation of the maximum amount of uplink resources the UE is allowed to use for uplink transmissions. Absolute grants are especially suitable to rapidly change the allocated UL resources.
Relative grants are transmitted every TTI (Transmission Time Interval). They may be used to adapt the allocated uplink resources indicated by absolute grants by granular adjustments: A relative grant indicates the UE to increase or decrease the previously allowed maximum uplink resources by a certain offset (step).
Absolute grants are only signaled from the E-DCH serving cell. Relative grants can be signaled from the serving cell as well as from a non-serving cell. The E-DCH serving cell denotes the entity (e.g. Node B) actively allocating uplink resources to UEs controlled by this serving cell, whereas a non-serving cell can only limit the allocated uplink resources, set by the serving cell. Each UE has only one serving cell.
Absolute grants may be valid for a single UE. An absolute grant valid for a single UE is referred to in the following as a “dedicated grant. Alternatively, an absolute grant may also be valid for a group of or all UEs within a cell. An absolute grant valid for a group of or all UEs will be referred to as a “common grant” in the following. The UE does not distinguish between common and dedicated grants.
Relative grants can be sent from serving cell as well as from a non-serving cell as already mentioned before. A relative grant signaled from the serving cell may indicate one of the three values, “UP”, “HOLD” and “DOWN”. “UP” respectively “DOWN” indicates the increase/decrease of the previously maximum used uplink resources (maximum power ratio) by one step. Relative grants from a non-serving cell can either signal a “HOLD” or “DOWN” command to the UE. As mentioned before relative grants from non-serving cells can only limit the uplink resources set by the serving cell (overload indicator) but can not increase the resources that can be used by a UE.
UE Scheduling Operation
This sections only outlines the principal scheduling operation, more details on the scheduling procedure is provided in 3GPP TS25.309 incorporated herein by reference. The UE maintains a Serving Grant (SG) which is common to all HARQ process, which indicates the maximum power ratio (E-DPDCH/DPCCH) the UE is allowed for the E-TFC selection. The SG is updated by the scheduling grants signaled from serving/non-serving cells. When the UE receives an absolute grant from the serving cell the SG is set to the power ratio signaled in the absolute grant. The absolute grant can activate/deactivate a single or all HARQ processes. As already mentioned before, an absolute grant can be received on primary or secondary E-RNTI. There are some precedence rules for the usage of primary/secondary absolute grants. A primary absolute grant always affects the SG immediately. Secondary absolute grants only affect the SG if the last primary absolute grant deactivated all HARQ processes, or if the last absolute grant that affected the SG was received with the secondary E-RNTI. When the transmission from primary to secondary E-RNTI is triggered, by deactivating all HARQ processes, the UE updates the Serving Grant with the latest received absolute grant on the secondary E-RNTI.
Therefore UE needs to listen to both primary and secondary E-RNTIs.
When no absolute grant is received from the serving cell the UE shall follow the relative grants from the serving cell, which are signaled every TTI. A serving relative Grant is interpreted relative to the UE power ratio in the previous TTI for the same hybrid ARQ process as the transmission, which the relative Grant will affect. FIG. 10 illustrates the timing relation for relative grants. The assumption here is that there are 4 HARQ processes. The relative grant received by the UE, which affects the SG of the first HARQ process, is relative to the first HARQ process of the previous TTI (reference process). Since a synchronous HARQ protocol is adopted for E-DCH the different HARQ processes are served successively.
The UE behavior in accordance to serving E-DCH relative grants is shown in the following:                When the UE receives an “UP” command from Serving E-DCH RLS                    New SG=Last used power ratio+Delta                        When the UE receives a “DOWN” command from Serving E-DCH RLS                    New SG=Last used power ratio—Delta                        
The “UP” and “DOWN” command is relative to the power ratio used for E-DCH transmission in the reference HARQ process. The new Serving Grant (SG) for all HARQ processes, affected by the relative grant, is an increase respectively decrease of the last used power ratio in the reference HARQ process. The “HOLD” command indicates that the SG remains unchanged.
As already mentioned before a Node B from a non-serving RLS is only allowed to send relative grants, which can either indicate a “HOLD” or “DOWN”. The “DOWN” command enables non-serving cells to limit the intercell-interference caused by UEs which are in SHO with these non-serving cells. The UE behavior upon reception of non-serving relative grants is as follows:                When the UE receives a “DOWN” from at least one Non-serving E-DCH RLS                    new SG=Last used power ratio—Delta                        
Relative grants from a non-serving RLS affect always all HARQ processes in the UE. The amount of reduction of the used power ratio might be static or depending on the bit rate, for higher bit rates there might be a larger step size (Delta).                When the UE receives a scheduling grant from the serving RLS and a “DOWN” command from at least one non-serving RL                    new SG=minimum (last used power ratio-delta, received AG/RG from serving RLS)Rate Request signaling                        
In order to enable Node B to schedule efficiently while considering also the QoS requirements of a service mapped on the E-DCH, an UE provides the Node B information on its QoS requirements by means of rate request signaling.
There are two kinds of rate request signaling information on the uplink: the so called “happy bit”, which is a flag related to a rate request on the E-DPCCH and the scheduling information (SI), which is commonly sent in-band on the E-DCH.
From a system point of view, the one-bit rate request may be advantageously used by the serving cell to effect small adjustments in the resource allocation for example by means of relative grants. On the contrary, scheduling information may advantageously be employed for making longer term scheduling decisions, which would be reflected in the transmission of an absolute grant. Details on the two rate request signaling methods are provided in the following.
Scheduling Information Sent on E-DCH
As mentioned before the scheduling information should provide Node B information on the UE status in order to allow for an efficient scheduling. Scheduling information may be included in the header of a MAC-e PDU. The information is commonly sent periodically to Node B in order to allow the Node B to keep track of the UE status. E.g. the scheduling information comprises following information fields:                Logical channel ID of the highest priority data in the scheduling information        UE buffer occupancy (in Bytes)                    Buffer status for the highest priority logical channel with data in buffer            Total buffer status                        Power status information                    Estimation of the available power ratio versus DPCCH (taking into account HS-DPCCH). UE should not take power of DCHs into account when performing the estimation                        
Identifying the logical channel by the logical channel ID from which the highest priority data originates may enable the Node B to determine the QoS requirements, e.g. the corresponding MAC-d flow power offset, logical channel priority or GBR (Guaranteed Bit Rate) attribute, of this particular logical channel. This in turn enables the Node B to determine the next scheduling grant message required to transmit the data in the UE buffer, which allows for a more precise grant allocation. In addition to the highest priority data buffer status, it may be beneficial for the Node B to have some information on the total buffer status. This information may help in making decisions on the “long-term” resource allocation.
In order for the serving Node B to be able to allocate uplink resources effectively, it needs to know up to what power each UE is able to transmit. This information could be conveyed in the form of a “power headroom” measurement, indicating how much power the UE has left over on top of that what is used for DPCCH transmissions (power status). The power status report could also be used for the triggering of a TTI reconfiguration, e.g. switching between 2 ms and 10 ms TTI and vice versa.
Happy Bit
As already explained above the happy bit denotes a one-bit rate request related flag, which is sent on the E-DPCCH. The “happy bit” indicates whether the respective UE is “happy” or “unhappy” with the current serving grant (SG).
The UE indicates that it is “unhappy”, if both of the following criteria are met:                Power status criterion: UE has power available to send at higher data rates (E-TFCs) and        Buffer occupancy criterion: Total buffer status would require more than n TTIs with the current Grants (where n is configurable).        
Otherwise, the UE indicates that it is “happy” with the current serving grant.
Hybrid ARQ Schemes
A common technique for error detection of non-real time services in mobile communication system is based on Automatic Repeat reQuest (ARQ) schemes, which are combined with Forward Error Correction (FEC), called Hybrid ARQ. If Cyclic Redundancy Check (CRC) detects an error, the receiver requests the transmitter to send additional bits or a new data packet. From different existing schemes the stop-and-wait (SAW) and selective-repeat (SR) continuous ARQ are most often used in mobile communication.
A data unit will be encoded before transmission. Depending on the bits that are retransmitted three different types of ARQ may be defined.
In HARQ Type I the erroneous data packets received, also called PDUs (Packet Data Unit) are discarded and new copy of that PDU is retransmitted and decoded separately. There is no combining of earlier and later versions of that PDU. Using HARQ Type II the erroneous PDU that needs to be retransmitted is not discarded, but is combined with some incremental redundancy bits provided by the transmitter for subsequent decoding. Retransmitted PDU sometimes have higher coding rates and are combined at the receiver with the stored values. That means that only little redundancy is added in each retransmission.
Finally, HARQ Type III is almost the same packet retransmission scheme as Type II and only differs in that every retransmitted PDU is self-decodable. This implies that the PDU is decodable without the combination with previous PDUs. In case some PDUs are heavily damaged such that almost no information is reusable self decodable packets can be advantageously used.
When employing chase-combining the retransmission packets carry identical symbols. In this case the multiple received packets are combined either by a symbol-by-symbol or by a bit-by-bit basis (see D. Chase: “Code combining: A maximum-likelihood decoding approach for combining an arbitrary number of noisy packets”, IEEE Transactions on Communications, Col. COM-33, pages 385 to 393, May 1985 incorporated herein by reference). These combined values are stored in the soft buffers of respective HARQ processes.
MAC Layer HARQ Operation at TTI Reconfiguration
As has been already indicated with respect to FIG. 10, usually more than one HARQ process is provided for the transmission of packet data units to improve system efficiency and to take into account the transmission delays. Commonly, the number of HARQ processes is preconfigured and may take into account the roundtrip time (RTT) and transmission time interval (TTI), such that for a given HARQ process feedback from the receiver is available at the beginning of the next transmission utilizing the respective HARQ process.
Considering UMTS, the E-DCH supports different TTIs, namely 2 ms and 10 ms. In a simple scenario cells would be both capable of 2 ms TTI and 10 ms TTI. UEs experiencing good channel conditions may for example be configured with a 2 ms-TTI and UEs experiencing bad channel conditions may be configured with 10 ms-TTI, since the interleaving gain is higher for longer TTIs.
One exemplary scenario may be that UEs in soft-handover (SHO) are configured with 10 ms TTI whereas UEs in not in soft-handover (non-SHO) are configured with 2 ms TTI. Every time a UE changes from non-SHO to SHO situation (or vice versa) the TTI reconfiguration is triggered.
Depending on the TTI length also the number of HARQ processes changes. For E-DCH operation in UMTS, it has been, for example, decided to utilize 4 HARQ processes for a 10 ms TTI and 8 HARQ processes in a 2 ms TTI.
The TTI reconfiguration procedure is part of the transport channel reconfiguration procedure in UMTS. A synchronized transport channel reconfiguration procedure is performed as illustrated for exemplary purposes in FIG. 11. Upon the S-RNC deciding to reconfigure the TTI for E-DCH transmissions, the S-RNC requests a Node B to prepare a radio link reconfiguration. The Node B allocates resources and notifies S-RNC that reconfiguration is ready, by using a Radio Link Reconfiguration Ready message via NBAP. In the next step a Radio Link Reconfiguration Commit message is sent from S-RNC to the Node B, which requests the Node B to switch to the new configuration at the indicated activation time. The S-RNC sends UE via RRC signaling a Transport Channel Reconfiguration message, which also includes an activation time. The UE answers with a Transport Channel Reconfiguration Complete message in response. By the definition of an activation time, it's guaranteed that UTRAN and UE switch to the new configuration at the same time instance synchronously.
When a TTI reconfiguration is triggered MAC-e PDUs transmitted utilizing the currently configured HARQ processes may be still in retransmission. Since TTI switching should be done fast when triggered, all ongoing HARQ processes that still have retransmissions outstanding at the time of TTI reconfiguration should be aborted/flushed. Aborting the pending (re)transmissions will, however, lead to an increase in the HARQ residual error ratio. Depending on whether RLC entities are operated in acknowledged mode (AM) or unacknowledged mode (UM), the abortion of retransmission will have a different impact on system level.
For RLCs in AM, there are RLC mechanisms that can be used for the recovery of the lost PDUs as will be described in the next section in further detail. Thus, there will be no impact on the SDU error rate at the expense of additional delay and also additional signaling.
For RLC in UM case the potential loss of MAC-e PDUs at TTI reconfiguration will result in a degradation of the experienced quality at service level. The extend of degradation of the end-to end quality depends mainly on how often a TTI reconfiguration is performed.
Radio Link Control Protocol
The radio link control protocol is the Layer 2 protocol used in 3G UMTS cellular systems for flow control and error recovery for both user and control data. There are three operational modes for RLC in UMTS: transparent mode (TM), unacknowledged mode (UM) and acknowledged mode (AM). Each RLC entity is configured by RRC to operate in one of these modes, as described in further detail in 3GPP TS 25.322, “Radio Link Control (RLC) protocol specification (Release 6)”, (incorporated herein by reference and available at http://www.3gpp.org). The service the RLC layer provides in the control plane is called Signaling Radio Bearer (SRB). In the user plane, the service provided by RLC layer is called a Radio Bearer (RB) only if the PDCP and BMC protocols are not used by that service; otherwise the RB service is provided by the PDCP layer or BMC layer.
In transparent mode (TM) no protocol overhead is added to RLC SDUs received from higher layer. In special cases transmission with limited segmentation/reassembly capability can be accomplished. It has to be negotiated in the radio bearer setup procedure, whether segmentation/reassembly is used. The transparent mode is mainly used for very delay-sensitive services like speech.
In unacknowledged mode (UM) data delivery is not guaranteed since no retransmission protocol is used. Hence received erroneous PDUs are discarded or marked depending on the configuration. The RLC SDUs, received from higher layer, are segmented/concatenated into RLC PDUs on sender side. On receiver side reassembly is performed correspondingly. Furthermore ciphering is performed in the RLC layer. The unacknowledged mode is used, for example, for certain RRC signaling procedures. Examples of user services are the cell broadcast service (MBMS), which is currently a work item in 3GPP, and voice over IP (VoIP).
The acknowledged mode (AM) is designed for a reliable transport of packet data. Multiple-Repeat ARQ is used for retransmission of erroneous or missed PDUs. Retransmission of erroneous or lost PDUs is conducted by the sending side upon receiving a status report from the receiver. The status report can be polled by the sender or self-triggered. The receiver sends a bitmap status report to the sender when it is polled. The report indicates the reception status (either ACKs or NACKs) within the receiving window and up to the last received PDU. More details on the retransmission protocol in RLC will be provided in the next subsection. An acknowledged mode RLC can be configured to provide both in-sequence and out-of sequence delivery to higher layers. As already mentioned before, in addition to data PDU delivery, status and reset control PDUs can be signaled between the peer entities. The control PDUs can be even transmitted on a separate logical channel, thus an RLC entity in AM can be configured to utilize two logical channels. The acknowledged mode is the default mode for packet-type services, such as interactive and background services.
The functions of the RLC layer may be summarized as follows:                Segmentation and reassembly        Concatenation        Padding        Error correction        In-sequence delivery to higher layer        Duplicate detection        Flow control        Sequence number check        Protocol error detection and recovery        Ciphering        Suspend/resume function for data transferRLC ARQ Protocol        
With multiple-reject ARQ, the RLC protocol provides a reliable service through retransmission to packet data applications over UMTS networks in the presence of high air interface bit error rates. In case of erroneous or lost PDUs retransmission is conducted by the sender upon reception of a status report from the receiver. There are multiple mechanisms available for triggering status reports:                Periodic: a report is triggered at fixed time intervals.        Missing PDU: a report is triggered if a break in the sequence number sequence is detected.        Reception of a poll: a report is triggered if a poll is received from the transmitter. For the sender, a polling request is made by marking the poll bit in the header of an outgoing RLC PDU. The possible triggers and inhibitors of polling are listed as follows:        Last PDU in Buffer: The poll bit is set when the last PDU in the transmission buffer is sent.        Last PDU in Retransmission Buffer: The poll bit is set when the last PDU in the retransmission buffer is sent.        Expiry of Poll Timer: A poll timer is started when a PDU with the poll bit set is sent. If a status report is received before the timer expires the timer is cancelled. If the timer expires and no status reports have been received, a PDU with the poll bit set is sent.        Window Based Polling: A poll is triggered after the transmission window has advanced more than a certain fraction of the transmission window.        Periodic Polling: A PDU with the poll bit set is sent periodically.        Every Poll_PDU PDU: The sender triggers the Polling function for every Poll_PDU PDU. Both retransmitted and new AMD PDUs (PDUs in Acknowledged Mode) shall be counted.        Every Poll_SDU SDU: The sender triggers the Polling function for every Poll_SDU SDU. The poll is triggered for the first transmission of the AMD PDU that contains the “Length Indicator” indicating the end of the SDU.        Poll_Prohibit_Timer: The Poll Prohibit function is used by the sender to delay the initiation of the Polling function. Under the circumstances where several poll triggering options are present simultaneously in a system, a potential risk is that the network could be overwhelmed by excessive polling and status reports sent over the air interface. In WCDMA (Wideband CDMA), which is the air interface technology for UMTS, an excessive polling of status reports would result in excessive power consumption and subsequently high level of interference to other users and reduction of overall system capacity. The poll_prohibit_timer can be implemented to deal with this problem of excessive polling and status report transmission. At the transmitter, the poll prohibit timer is started once a PDU with the poll bit set is sent. No polling is allowed until this timer expires. If multiple polls were triggered during the period when this timer was in effect, only one poll is transmitted upon expiry of the timer.        
The RLC in AM at the receiver commonly maintains a number of state variables. In the following only those state variables are described, which are of particular interest for the generation of status reports:                VR(R): latest in-sequence received sequence number (marks the beginning of the receiver window)        VR(H): highest sequence number for any PDU received        VR(MR): highest sequence number that will be accepted as valid (marks the end of the receiver window and is set exactly to VR(R)+RxWindowSize).        
Probably the most important aspect of status reports is that every single report needs to include all the sequence number gaps that exist between VR(R) and VR(H). In order to avoid excessive polling and status reports and hence the involved triggering of spurious, i.e. un-necessary, re-transmissions, the poll-prohibit function was introduced as already mentioned before.
The STATUS prohibit function is used in order to prohibit the receiver from sending a status report. The transmission of the status report is delayed, even if any of the triggering conditions above are fulfilled. An exception is made for the generation of a status report triggered by a MAC-hs reset. Similar to the Poll_Prohibit_Timer there is a STATUS_Prohibit_Timer in the receiving entity                STATUS_Prohibit_Timer: The timer Timer_Status_Prohibit is started when a status is sent out. If a status report is triggered while the corresponding timer is running, its transmission will be delayed until the said timer expires. To ensure that spurious re-transmissions are not triggered, the STATUS_Prohibit_Timer should be set to a value slightly longer than the expected round-trip-time. This will give enough time for the NACKs to be received on the other side and the re-transmissions to make their way to the receiver before the next status report is sent out.        
As already explained above, there is a potential risk for a loss of PDUs due aborting/flushing pending HARQ (re)transmission upon TTI reconfiguration. There are several RLC mechanisms to recover lost PDUs for RLC in AM mode:                The receiving entity in the S-RNC detects missing PDUs        The transmitting entity in UE polls the receiving entity for sending a status report        
In the first case, the receiving entity in SRNC detects missing PDUs. Upon detection of missing PDUs RLC generates a status report, which is sent to the transmitting entity. The UE just starts after TTI reconfiguration with the transmission of RLC PDUs from where it stopped before TTI switching. The RLC receiving entity recognizes the out-of sequence delivery of data and then generates an RLC status report indicating the missing PDUs. The UE will upon reception of the RLC status report initiate the retransmission of the indicated PDUs. There is some latency inherited in this scheme since RLC receiving entity in SRNC needs to rely on receiving RLC PDUs after the TTI reconfiguration. The RLC PDU reception required for determining missing PDUs suffers from queuing delay in the UE, successful reception at Node B after HARQ processing and the lub delay. Therefore it's not possible to recover lost PDUs with minimal delay after TTI switching when relying on this mechanism.
In the second case, the transmitting entity in UE polls the receiving entity for a status report. The polling is done after the TTI reconfiguration procedure is completed. The UE first polls each RLC AM entity mapped to E-DCH for the generation of a status report. After receiving the status report at the UE, the retransmission of the lost PDUs can be initiated. Ideally the time instant for UE polling should be done as soon as the TTI reconfiguration is completed in order to allow for fast recovery. However as outlined in a previous section the triggers for polling a status report are not aligned with the TTI reconfiguration but are tied to predefined events like for example timers.
In conclusion both schemes described above suffer from a delayed generation of status reports after the TTI reconfiguration.
This operation, however, does also not allow for a fast and efficient recovery of lost PDUs. In case transmission is performed in the AM mode, data PDUs are only delivered from RLC to higher layers if in-sequence delivery can be provided. Therefore a fast processing of lost PDUs is required in order not to stall the RLC protocol and hence to degrade the quality of service.